The present invention relates generally to traffic management and more particularly to a high speed computational engine that performs transmission rate calculations for the purpose of flow control in a communications network.
Communications networks are comprised of many components including telecommunications switches that route voice and/or data packets to and from various devices (i.e. sources and destinations) that are connected to the network. These devices include telephones, facsimile machines, routers, servers, and/or other switches. The telecommunications switches perform many complex functions to manage data traffic. By managing data traffic, the switch more efficiently uses its available bandwidth thereby providing users with improved Quality of Service (QoS).
An ATM network, which is an example of a communications network, has a number of available QoS classes including: constant bit rate (CBR), real-time variable bit rate (VBR-RT), non-real-time variable bit rate (VBR-NRT), unspecified bit rate (UBR), and available bit rate (ABR). CBR and VBR are typically dedicated for handling real-time communication such as voice and video while ABR/UBR is typically dedicated for handling data communication. ATM switches, in an ATM network, may use traffic load information to calculate the allowed data rates that can pass through them. For instance, ABR data rates are sent to various devices connected to the network using resource management (RM) cells. RM cells include forward resource management (FRM) cells and backward resource management (BRM) cells.
In a point-to-point communication, a source sends an FRM cell every so often, for example every 32 cell transmissions. The FRM cell indicates, for the given data transmission, the rate at which the source is transmitting data (e.g. 10 Mbps). The FRM cells propagate through the network until they are received by a destination. The destination processes each FRM cell and produces, therefrom, a BRM cell, which indicates that the current data rate of the source is acceptable, too slow, or too fast. Such an indication may be given by a congestion indication (CI) bit and a no increase (NI) bit, and/or an explicit rate (ER) value. For example, the destination, or an intervening switch, sets the CI bit when the source data rate is too fast, sets the NI bit and clears the CI bit when the source data rate is acceptable, and clears both the CI and NI bits when the source data rate is too slow. Alternatively, the destination, or intervening switch, may calculate an ER value to indicate a data rate that is acceptable. Note that a source may be an end user device (e.g., personal computer) or a virtual source (i.e., a switch that functions, with respect to a destination, as a source). Further note that a destination may be an end user device or a virtual destination (i.e., a switch that functions, with respect to a source, as a destination).
The BRM cell propagates through the network until it is received by the source. The source processes the BRM cell to adjust its data rate accordingly. For example, the source incrementally adjusts its data rate based on the CI and NI bits or it adjusts its data rate to that indicated by the ER value. This process continues throughout the communication, such that for each BRM cell received, the source, if needed, adjusts its data rate.
An explicit rate (ER) computational engine executes an ER algorithm to determine the ER value. In general, the ER algorithm attempts to fairly distribute bandwidth between ABR connections at a contention point (i.e., at a data traffic queuing point within a switch).
An ER computational engine might include a control unit with programming instruction interpreter, and a datapath. The datapath consists of execution units such as arithmetic logic units (ALUs) or shifters, registers, and interconnecting communication paths. The datapath processes ER information based on commands (control signals), provided by the control unit, to produce the ER value. The source code for the programming instructions (i.e. machine code, object code), are generally written in assembly languageare processed by an interpreter within the control unit. The interpreter converts the programming instructions into a sequence of micro instructions (commands), which are then provided to the data path.
An issue with interpreters is their complex design and cost of implementation. The interpreter design complexity is of reduced concern when a processor engine is being developed to execute complex, diverse, and/or lengthy algorithms since programmers benefit by being able to describe, design, and update algorithms more efficiently using assembly language, as opposed to specifying the individual datapath commands (i.e., micro instructions). The ER engine, however, performs only ER calculations and is required to do them very frequently (e.g., once every 400 nanoseconds). As such, the ER engine requires speed and efficiency in determining the ER value (which is limited by having to interpret each programming instruction) while remaining flexible enough to accommodate future changes to the ER computation algorithm without changing the ER engine itself. Thus, improving the speed and efficiency in which the ER engine calculates ER values will improve the bandwidth utilization of a line or trunk.
Therefore, a need exists for a high speed, low cost, flexible ER computational engine that increases the efficiency of the network by providing efficient, real time, ER calculations without the need for an interpreter.
Therefore, a need exists for a high speed, low cost, flexible ER computational engine that increases the efficiency of the network by providing efficient, real time, ER calculations without the need for an interpreter.